一年前的高管們決定開(kāi)始一個(gè)新項(xiàng)目——?jiǎng)?chuàng)建一款旗艦產(chǎn)品，作為解決方案組合的一部分。高管們對(duì)產(chǎn)品開(kāi)發(fā)方式提出了挑戰(zhàn)，并希望探索快速推出產(chǎn)品的新方法。經(jīng)過(guò)內(nèi)部討論，決定嘗試一種開(kāi)發(fā)產(chǎn)品的新方法。決定與 DevOps 團(tuán)隊(duì)合作。在本文中的 SCRUM 大師 Peter Borg 解釋了過(guò)渡到 DevOps 文化的必要步驟和要克服的挑戰(zhàn)。

過(guò)渡到 DevOps 的步驟

從歷史上看，該公司在傳統(tǒng)的敏捷設(shè)置中遇到了一些問(wèn)題，這導(dǎo)致了項(xiàng)目交付的延遲。如果 SCRUM 團(tuán)隊(duì)正在全速運(yùn)行以實(shí)現(xiàn)目標(biāo)，但基礎(chǔ)設(shè)施尚未準(zhǔn)備好，則交付會(huì)延遲。部門隔離可能會(huì)造成支持團(tuán)隊(duì)可能沒(méi)有資源來(lái)支持 SCRUM 團(tuán)隊(duì)的情況。僅一個(gè)部門并不能交付軟件產(chǎn)品，而這正是我們希望通過(guò)過(guò)渡到 DevOps 來(lái)改變的。

1. 創(chuàng)建自給自足的團(tuán)隊(duì)

為了啟動(dòng)新的 DevOps 文化變革，我們組建了一個(gè)新團(tuán)隊(duì)，其職位描述對(duì)公司來(lái)說(shuō)是獨(dú)一無(wú)二的。我們從全棧開(kāi)發(fā)人員轉(zhuǎn)向 DevOps 軟件工程師，從系統(tǒng)管理員轉(zhuǎn)向站點(diǎn)可靠性工程師 (SRE)。

通過(guò)這樣做，我們能夠組建一個(gè)自給自足的團(tuán)隊(duì)，其目標(biāo)是交付手頭的項(xiàng)目。除了在新技術(shù)堆棧的特定方面擁有專業(yè)知識(shí)外，雇用合適的人也至關(guān)重要，他們可以在不依賴團(tuán)隊(duì)外部人員的情況下交付產(chǎn)品。

SRE 的任務(wù)是對(duì)基礎(chǔ)架構(gòu)進(jìn)行編碼，軟件工程師負(fù)責(zé)開(kāi)發(fā)應(yīng)用程序，QA 工程師負(fù)責(zé)建立自動(dòng)化測(cè)試框架，軟件和系統(tǒng)架構(gòu)師負(fù)責(zé)設(shè)計(jì)解決方案。

盡管人們根據(jù)他們的知識(shí)領(lǐng)域被指定用于特定任務(wù)，但我們促進(jìn)了知識(shí)的交叉授粉。SRE 為軟件代碼做出了貢獻(xiàn)，軟件工程師參與了我們的 基礎(chǔ)設(shè)施即代碼 (IaC)，QA 參與了我們的測(cè)試驅(qū)動(dòng)開(kāi)發(fā) (TDD) 策略和持續(xù)集成 (CI) 管道，架構(gòu)師幫助開(kāi)發(fā)和故障排除。

2. 擁抱測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

每個(gè)人都討厭大爆炸式發(fā)布，這會(huì)導(dǎo)致發(fā)現(xiàn)后期集成問(wèn)題、重構(gòu)復(fù)雜解決方案以及可能的產(chǎn)品愿景分歧等問(wèn)題。

為了不陷入這些陷阱，我們選擇了 測(cè)試驅(qū)動(dòng)開(kāi)發(fā) (TDD)。TDD 使我們能夠分解、實(shí)施、測(cè)試、審查和擴(kuò)展復(fù)雜的解決方案，同時(shí)在我們構(gòu)建產(chǎn)品的過(guò)程中始終從產(chǎn)品負(fù)責(zé)人 (PO) 那里獲得反饋。這種迭代方法和反饋循環(huán)使我們能夠在建立堅(jiān)實(shí)的基礎(chǔ)后繼續(xù)改進(jìn)功能，這是敏捷宣言中的第一條原則（Kent Beck 等人，2001）。采用 DevOps 方法時(shí)要牢記的最重要的考慮因素是確保團(tuán)隊(duì)不會(huì)在情感上將自己與他們的實(shí)施聯(lián)系在一起，因?yàn)樗赡苡幸惶鞎?huì)在那里，但第二天就會(huì)消失。

通過(guò)選擇 TDD 方法，我們用非過(guò)度設(shè)計(jì)的解決方案實(shí)現(xiàn)了復(fù)雜的問(wèn)題。TDD 是一種迭代方法來(lái)開(kāi)發(fā)功能，使重構(gòu)更容易實(shí)現(xiàn)，同時(shí)還增加了解決方案的質(zhì)量。“從某個(gè)地方開(kāi)始，從經(jīng)驗(yàn)中學(xué)習(xí)”（John Shook。2008 年。管理學(xué)習(xí)：使用 A3 管理流程解決問(wèn)題、獲得共識(shí)、導(dǎo)師和領(lǐng)導(dǎo)）。

3. 推動(dòng) DevOps 文化變革

引入文化變革不僅很難。這令人筋疲力盡，令人沮喪和士氣低落。在多結(jié)構(gòu)組織中推動(dòng)不同的思維方式比在初創(chuàng)公司中建立公司文化要困難得多。

這就是為什么我相信通過(guò)以同樣的方式對(duì)待他們可以實(shí)現(xiàn)改變。如果您試圖在一家已經(jīng)建立的公司內(nèi)構(gòu)建不同的實(shí)施方法，那么只有創(chuàng)建一個(gè)小型組織生態(tài)系統(tǒng)才能實(shí)現(xiàn)。形成公司在實(shí)施新項(xiàng)目時(shí)將其視為初創(chuàng)公司的團(tuán)隊(duì)結(jié)構(gòu)。

您將面臨限制，例如“這不是我們做事的方式”或“我們已經(jīng)為此提供了不同的工具”。如果你聽(tīng)到這些陳述，你就走在了正確的軌道上。提出文化變革時(shí)，首先需要做的就是質(zhì)疑公司的流程和工具。考慮現(xiàn)有的工具和方法是否完全相關(guān)。

在我們的案例中，通過(guò)質(zhì)疑，我們能夠利用 云原生技術(shù) ，而不是公司認(rèn)為“標(biāo)準(zhǔn)”的系統(tǒng)。在推動(dòng) DevOps 變革時(shí)，您不會(huì)得到所有人的支持。然而，獲得高層管理人員的支持至關(guān)重要。這將有助于激勵(lì)公司內(nèi)部不太愿意改變的人，因?yàn)樵妇暗玫搅烁吖芾韺拥闹С帧?/p>

4. 測(cè)試你的進(jìn)步

在各個(gè) DevOps 過(guò)渡階段測(cè)試您的工作進(jìn)度。從測(cè)試速度開(kāi)始。您希望敏捷并快速實(shí)施解決方案。通過(guò)將“啟動(dòng)”項(xiàng)目與其他正在進(jìn)行或歷史的解決方案進(jìn)行比較，您應(yīng)該能夠了解 DevOps 團(tuán)隊(duì)是否交付得更快。衡量團(tuán)隊(duì)適應(yīng)變化的能力也很重要。如果反饋回路的變化結(jié)果是對(duì)系統(tǒng)的大修，那么在設(shè)計(jì)階段就出現(xiàn)了問(wèn)題。

其次，通過(guò)分析團(tuán)隊(duì)的士氣來(lái)衡量成功。當(dāng)引入新的實(shí)施適應(yīng)時(shí)，人們應(yīng)該感到興奮和積極。你會(huì)意識(shí)到你已經(jīng)通過(guò)無(wú)意中聽(tīng)到團(tuán)隊(duì)中的某個(gè)人與團(tuán)隊(duì)外部的某個(gè)人交談，解釋我們?nèi)绾问褂眯碌男膽B(tài)或技術(shù)解決問(wèn)題，這對(duì)公司來(lái)說(shuō)是新的。這將激發(fā)其他團(tuán)隊(duì)的興趣，并且在這一點(diǎn)上，您會(huì)意識(shí)到文化變革正在整個(gè)組織中蔓延。考慮一下成功的真正衡量標(biāo)準(zhǔn)——新的 DevOps 方法受到關(guān)注。其他團(tuán)隊(duì)成員想嘗試不同的事情，并就如何使用 DevOps 解決方案向您尋求建議。

5. 毫不妥協(xié)

當(dāng)我擔(dān)任 SCRUM Master 的角色時(shí)，我知道我必須盡快交付新產(chǎn)品和 DevOps 文化變革。必須在整個(gè)產(chǎn)品開(kāi)發(fā)階段保持這兩個(gè)目標(biāo)一致。面對(duì)此類挑戰(zhàn)時(shí)，高管的認(rèn)同和信任可以成就或破壞文化變革。有時(shí)，管理層可能不會(huì)關(guān)心項(xiàng)目是如何實(shí)現(xiàn)的，只要它已經(jīng)交付——即使我們不得不使用過(guò)時(shí)的技術(shù)。

這讓我想到了下一點(diǎn)，從一張空白畫(huà)布開(kāi)始。不要試圖將當(dāng)前的公司標(biāo)準(zhǔn)融入到 DevOps 開(kāi)發(fā)軟件的方式中。從頭開(kāi)始并保持精益解決方案。讓團(tuán)隊(duì)研究解決問(wèn)題的最佳工具。如果他們確定了公司已經(jīng)在使用的解決方案，那就太好了。如果他們不這樣做，那么將新工具展示給支持當(dāng)前解決方案的任何人，以獲得他們的支持來(lái)改變它。確保團(tuán)隊(duì)牢記沒(méi)有什么是一成不變的，工具可以改變，有人可能有更好的想法，需求也可以改變；它是迭代的。

6. 將其他團(tuán)隊(duì)過(guò)渡到 DevOps

一旦這個(gè)微型組織內(nèi)的 DevOps 文化變革開(kāi)始結(jié)出碩果，您就需要考慮下一步—— 增長(zhǎng)。如何讓更多團(tuán)隊(duì)過(guò)渡到 DevOps？

豐田生產(chǎn)系統(tǒng) (TPS) 理念（Toshiko Narusawa 和 John Shook. 2009. Kaizen Express）似乎符合 Spotify 的敏捷擴(kuò)展模型。保持一個(gè)盡可能扁平和獨(dú)立的組織結(jié)構(gòu)是關(guān)鍵。這賦予了團(tuán)隊(duì)權(quán)力，使他們對(duì)自己的成功和失敗更加負(fù)責(zé)。與其組建由相同技能人員組成的部門，不如設(shè)立“分會(huì)”，讓這些成員組成 SCRUM 團(tuán)隊(duì)的一部分，并鼓勵(lì)他們相互聯(lián)系以幫助解決問(wèn)題。促進(jìn)持續(xù)的溝通保持團(tuán)隊(duì)內(nèi)的項(xiàng)目?jī)?yōu)先級(jí)。

設(shè)置知識(shí)共享活動(dòng)，以告知其他部門團(tuán)隊(duì)已做出的任何技術(shù)決策。知識(shí)共享將有助于推動(dòng)整個(gè)公司向 DevOps 的過(guò)渡，并在整個(gè)組織中獲得支持。在過(guò)去的一年里，我們學(xué)到了很多東西，并且我們一直在尋找通過(guò)不同迭代來(lái)改進(jìn)我們的流程和結(jié)構(gòu)的方法。保持精益和敏捷的心態(tài)并確保產(chǎn)品是成功的故事將是維持的最重要因素。

關(guān)于切換到 Devops 的最終建議

對(duì)于任何過(guò)渡到 DevOps 的人來(lái)說(shuō)，最后也是最關(guān)鍵的一點(diǎn)是永遠(yuǎn)不要放棄。有時(shí)你會(huì)認(rèn)為擁抱 DevOps 文化很難實(shí)現(xiàn)，但如果你有來(lái)自團(tuán)隊(duì)、管理層和高管的正確支持系統(tǒng)，你就會(huì)成功。有一天，來(lái)自另一個(gè)團(tuán)隊(duì)的人會(huì)要求開(kāi)會(huì)，想知道你是如何實(shí)施某事的。那時(shí)你會(huì)意識(shí)到公司正走在接受 DevOps 文化的正確軌道上。分階段將理念從一個(gè)團(tuán)隊(duì)傳播到另一個(gè)團(tuán)隊(duì)，并花時(shí)間將整個(gè)組織轉(zhuǎn)移到 DevOps。